Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/textfile/faqs/elm/diff

Internet Message Format | 1992-12-26 | 21.4 KB

Xref: bloom-picayune.mit.edu comp.mail.elm:8535 news.answers:4591
Path: bloom-picayune.mit.edu!enterpoop.mit.edu!news.media.mit.edu!micro-heart-of-gold.mit.edu!news.bbn.com!olivea!spool.mu.edu!dsinc!dsinc!not-for-mail
From: [e-mail] (Syd Weinstein)
Newsgroups: comp.mail.elm,news.answers
Subject: Changes to the Monthly Elm Posting from the Elm Development Group
Keywords: diffs monthly elm posting
Message-ID: <[e-mail]>
Date: 15 Dec 92 01:46:54 GMT
Sender: [e-mail]
Followup-To: poster
Organization: Datacomp Systems, Inc., Huntingdon Valley, PA 19006
Lines: 464
Approved: [e-mail]
NNTP-Posting-Host: dsinc.dsi.com

Archive-name: elm-monthly/diff

*** o.elm.monthly    Tue Nov 10 15:27:10 1992
--- elm.monthly    Mon Dec 14 20:46:21 1992
***************
*** 15,29 ****
  this posting or Elm itself to [e-mail] (dsinc!elm).  See the
  README section of this posting for info on some Elm 2.4 FAQ's.
  This posting generated:
! Tue Nov 10 15:24:15 EST 1992

! Current release version: Elm 2.4 PL8
      This version was released at patch level 0.
      comp.sources.unix Posting-number: (Not yet posted)
      Archive-name: (Not yet posted)
      Patches are posted to comp.sources.bugs and comp.mail.elm
      After they are stable, patches are sent to comp.sources.unix
!         Five patch sets have been posted, 1/2, 3, 4/5, 6, 7/8.
          Archive-name: (No patches yet posted to comp.sources.unix)
      Patches are available from the archive server at DSI.COM:
      send mail to [e-mail]
--- 15,30 ----
  this posting or Elm itself to [e-mail] (dsinc!elm).  See the
  README section of this posting for info on some Elm 2.4 FAQ's.
  This posting generated:
! Mon Dec 14 20:46:08 EST 1992

! Current release version: Elm 2.4 PL17
      This version was released at patch level 0.
      comp.sources.unix Posting-number: (Not yet posted)
      Archive-name: (Not yet posted)
      Patches are posted to comp.sources.bugs and comp.mail.elm
      After they are stable, patches are sent to comp.sources.unix
!         The following patch sets have been posted, 1/2, 3, 4/5,
!             6, 7/8, 9/10, 11, 12/13, 14-17.
          Archive-name: (No patches yet posted to comp.sources.unix)
      Patches are available from the archive server at DSI.COM:
      send mail to [e-mail]
***************
*** 136,141 ****
--- 137,197 ----
      think that the message is 'remote'. This is not slated to
      change until 3.0.

+ Why Elm adds your local hosts qualification to reply addresses:
+ (Or why the DANGER WILL ROBINSON KLUDGE is in the code)
+     Elm passes any address off to the alias mapper to see if it
+     needs expansion.  If you are replying to a bare user name of
+     abc, Elm converts it to [e-mail] (assuming internet
+     addressing, myhost!abc for the rest).  This is to prevent the
+     alias expansion.  If you were to have, in you private Elm alias
+     table an alias of abc that pointer to
+     [e-mail], if the address wasn't qualified,
+     Elm would convert the reply to abc to go to
+     [e-mail].  This is generally not what you
+     want :-)
+
+ If you can guarantee that no private alias will ever match a local user
+ name on your system, then you can disable the kludge code.  The kludge
+ will have to remain until 3.0 when Elm will track whether an address
+ has been/should be expanded, and its prior to and after expansion values.
+ In 2.x it doesn't do that.
+
+ How can I get elm to NOT expand the alias list on outgoing msgs?
+ Problem is if a list has, say, 100 names in it then sending to the list
+ expands every single one of the 100 names. I would like the message to
+ have the "To" line = the name of the list itself and have the actual
+ recipients' names not appear.
+     You can't and don't want to. (and yet you can also) An alias is
+     a mechanism of making Elm address a message to multiple
+     people.  However, when the message gets to its destination, Elm
+     also has to allow that person do a group reply.  If the message
+     only has your local private elm alias in it, the group reply
+     will try and go to that alias name.  Unfortunately, that name
+     is meaningless to that other person (its private to both Elm
+     and you).
+
+     There are two solutions:
+
+     The preferred if replies are desired:
+         Have your mail administrator create a file include
+         alias for you in your MTA (sendmail, et al).. This is
+         usually of the type
+
+     alias    :include:/some/path/to/a/file
+
+     where the file would be in a place you control and you have write access
+     to the file.  Then you can add/drop members of the list, and
+     the mail just goes to the alias, and, someone sending to
+     [e-mail] will be able to send to all members. (group
+     reply works correctly)
+
+     The less preferred method: (no group reply is possible)
+         Send the message to yourself, with a bcc to the Elm
+         alias.
+     Of course, the Bcc: won't be expanded by the MTA internal to
+     the message, so it won't appear in the message.
+
+
  From comp.mail.elm, [e-mail] (DaviD W. Sanderson) writes:
  >... whoever wrote the default termcap
  >and/or terminfo descriptions for xterm included in the ti/te strings
***************
*** 195,201 ****
  at the same time we are working on the next release.  Also starting with
  release 2.2 a list of known problems will be published in this posting.

! Known bugs in Elm 2.4 PL5:
      The following are from the Elm 2.4 "To.Do" list that are
  considered bugs, not enhancements, that have not yet been done.  Items
  which are enhancements are not listed here.  It is our intention to
--- 251,257 ----
  at the same time we are working on the next release.  Also starting with
  release 2.2 a list of known problems will be published in this posting.

! Known bugs in Elm 2.4 PL13:
      The following are from the Elm 2.4 "To.Do" list that are
  considered bugs, not enhancements, that have not yet been done.  Items
  which are enhancements are not listed here.  It is our intention to
***************
*** 204,298 ****
  change is to fix it, and what else it ties into in the 3.0 work).
  Items marked fixed will be deleted from the list on the next posting.

- 1.  General bugs and configuration bugs

! GB01 The ordering of some sets of configuration    questions could
!      be    improved.  In some cases, the answer to    a later    question
!      renders an    earlier    question moot.    In such    cases, the latter
!      should proceed the    former so that the former would    only be
!      asked if need be.

! GB02 All programs need to use the same algorithm elm(1)    and
!      frm(1) use    in establishing    the user's id and the user's in-
!      coming mailbox.

- GB10 [next item    goes here]

! 2.  Elm(1) bugs

- EB02 Encryption    is not fully implemented in ELM.  In elm(1) we
-      have the following    problems:

!      When `b' (bouncing) a message or `f' (forwarding) a message
!      without editing, an encrypted section of text in the origi-
!      nal message wrongly gets encrypted    a second time.    The func-
!      tion that looks for encryption delimiters needs to    know to
!      ignore them in these situations.

-      When `p' (printing) or `|'    (piping) a message, an encrypted
-      message does not get decrypted.  This is because elm(1) in-
-      vokes readmsg(1) to pull the message out of the folder and
-      readmsg(1)    does not deal with encryption at all.  Even if we
-      gave readmsg(1) the ability to decrypt messages, we'd still
-      have problems because readmsg itself would    have to    prompt
-      for the decryption    key.  Now if we    were printing or piping    a
-      set of tagged messages, readmsg(1)    would have to prompt for
-      decryption    keys for each message individually.  In    doing
-      that readmsg(1) would have    to indicate which message of the
-      set it was    working    on.  This would    be difficult since
-      readmsg(1)    uses actual ordinal message position in    the fold-
-      er, and that would    be confusing if    the user has folders
-      sorted in other than mailbox order: the message numbers
-      wouldn't match up.     The solution therefore    involves replac-
-      ing readmsg(1) with a new function    in elm(1) to handle the
-      `p' or `|'    commands, and this function would need to detect
-      the encryption delimiters and prompt for the decryption key.
-      Furthermore, readmsg(1) should get    enhanced to deal with en-
-      crypted text, or else carry a disclaimer that it doesn't
-      work on encrypted text.

-      When including the    text of    an original message for    a `r'
-      (reply) or    `f' (forward), encrypted sections do not get de-
-      crypted first, resulting in decrypted text    inside the in-
-      clude text.  This means that the elm(1) function that in-
-      cludes text of an original    message    must detect encryption
-      delimiters    and decrypt encrypted text before including it in
-      a reply or    forwarded message.

! EB26 When using    an address of the form "node!user@domain" and
!      having Elm    convert    it to an all ! address,    RFC976 states
!      that the proper address should be domain!node!user, but Elm
!      translates    that to    node!domain!user.

- EB36 When Elm is configured not    to look    at the password    file for
-      full name information, it sometimes places    the user name in
-      ()s as the    comment    in addition to the full    name.

! EB41 [next item    goes here]

! 3.  Utilities bugs

! UB02 Newmail(1)    displays a null    "From" when a message does not
!      contain a From: header line.  It needs to be able to parse
!      the return    path and display the "last two words" of it, just
!      like elm(1) does  when it encounters a message without a
!      From:

! UB07 Arepdaemon    has a bad security hole    because    it does    not check
!      to    see if the user    can read the file used for reply.

! UB09 Autoreply.c tries to unlink the file "/etc/autoreply.data"
!      when there    is only    one entry in it    and does not check the
!      return value of unlink.  This can have bad    repercussions if
!      the unlink    fails because the program nevertheless reports
!      success.

! UB13 If    filter is run on a system that allows multiple delivery
!      agents, that can start up multiple    copies of filter,
!      delivery of messages can get intermixed.  Filter needs a
!      complete interlocking to prevent this.

! UB14 [next item    goes here]



--- 260,501 ----
  change is to fix it, and what else it ties into in the 3.0 work).
  Items marked fixed will be deleted from the list on the next posting.


! Database last updated on Thursday  3-December-92 14:52:04 +0000 (GMT)

! General bugs and configuration bugs
! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


! GB01  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Configuration questions need rearranging
!       Description:
!           The ordering of some sets of configuration questions could be
!           improved.  In some cases, the answer to a later question
!           renders an earlier question moot.  In such cases, the latter
!           should proceed the former so that the former would only be
!           asked if need be.  This occurs with many of the configuration
!           questions that deal with the domain routing and pathalias
!           databases, appending the hostname and internet address style,
!           etc.


! GB02  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     User id & mailbox algorithm should be consistant.
!       Description:
!           All programs need to use the same algorithm elm(1) and frm(1)
!           use in establishing the user's id and the user's incoming
!           mailbox.



! Elm(1) bugs
! ~~~~~~~~~~~


! EB02  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Encryption is not fully implemented in ELM.
!       Description:
!           In elm(1) we have the following problems:

!           When `b' (bouncing) a message or `f' (forwarding) a message
!           without editing, an encrypted section of text in the original
!           message wrongly gets encrypted a second time. The function
!           that looks for encryption delimiters needs to know to ignore
!           them in these situations.

!           When `p' (printing) or `|' (piping) a message, an encrypted
!           message does not get decrypted. This is because elm(1) invokes
!           readmsg(1) to pull the message out of the folder and
!           readmsg(1) does not deal with encryption at all.

!           Even if we gave readmsg(1) the ability to decrypt messages,
!           we'd still have problems because readmsg itself would have to
!           prompt for the decryption key.

!           Now if we were printing or piping a set of tagged messages,
!           readmsg(1) would have to prompt for decryption keys for each
!           message individually. In doing that readmsg(1) would have to
!           indicate which message of the set it was working on.

!           This would be difficult since readmsg(1) uses actual ordinal
!           message position in the folder, and that would be confusing if
!           the user has folders sorted in other than mailbox order: the
!           message numbers wouldn't match up. The solution therefore
!           involves replacing readmsg(1) with a new function in elm(1) to
!           handle the `p' or `|' commands, and this function would need
!           to detect the encryption delimiters and prompt for the
!           decryption key. Furthermore, readmsg(1) should get enhanced to
!           deal with encrypted text, or else carry a disclaimer that it
!           doesn't work on encrypted text.

!           When including the text of an original message for a `r'
!           (reply) or `f' (forward), encrypted sections do not get
!           decrypted first, resulting in decrypted text inside the
!           include text. This means that the elm(1) function that
!           includes text of an original message must detect encryption
!           delimiters and decrypt encrypted text before including it in a
!           reply or forwarded message.
!
!
! EB26  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Addresses "node!user@domain" not handled as RFC976
!       Description:
!           When using an address of the form "node!user@domain" and
!           having Elm convert it to an all ! address, RFC976 states that
!           the proper address should be domain!node!user, but Elm
!           translates that to node!domain!user.
!
!
! EB36  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Sometimes user name is added into full name field
!       Description:
!           When Elm is configured not to look at the password file for
!           full name information, it sometimes places the user name in
!           ()s as the comment in addition to the full name.
!
!
! EB41  Version:     2.3PL11          Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (Rob Price)
!       Summary:     Incoming mail incorrectly handled in subset mode.
!       Description:
!           If a subset of mail is displayed using the "l" command, new
!           incoming mail is displayed with the subset mail.  However the
!           mail count at the top of the screen is not updated, and the
!           final few items (ie those numerically after the number of
!           messages shown) cannot be selected by the cursor keys.
!
!
! EB42  Version:     2.4PL3           Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (Jim Moore)
!       Summary:     Builtin editor unable to delete back over line boundary.
!       Description:
!           The builtin editor is unable to delete back over a line
!           boundary.  Attempts to delete back over a line boundary can
!           cause the whole message to be lost, and unpredictable effects
!           to be seen on screen and possibly garbage characters in the
!           file.
!
!
! EB43  Version:     2.4PL3           Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (Andrew Cytron)
!       Summary:     Elm does not enforce newline at end of message.
!       Description:
!           Some MTAs (notably Sun sendmail) require that the message end
!           in a newline character.  Elm does not enforce this, which can
!           result in the MTA failing or hanging.
!
!
! EB44  Version:     2.4PL6           Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (Marc Pawliger)
!       Summary:     Builtin editor treats "/" as white space char.
!       Description:
!           The builtin editor treats "/" as a whitespace character and
!           performs wordwrap (including deleting the "/") on things such
!           as file names.
!
!
! EB45  Version:     2.4devPL65       Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (Joe Greco)
!       Summary:     Incoming messages can confuse the index screen display.
!       Description:
!           Elm can lose track of incoming (new) messages so that although
!           the number of messages at the top of the screen is correct,
!           the new messages are not displayed on the index page.  However
!           these messages can be accessed in the normal way, they just
!           aren't listed in the index.  Redrawing the screen restores
!           things to normal.
!
!
! EB46  Version:     2.4PL13          Status:     Open
!       Open Date:   2-Dec-92         Close Date:
!       Reported by: [e-mail] (J. Philip Miller)
!       Summary:     To: addresses split over lines can confuse group reply.
!       Description:
!           If an address in the To: part of a message is split over more
!           than one line, a group reply to that message will incorectly
!           parse the addresses and build an incorrect Cc: header.
!
!           The example given had the fullname part of an address in ()
!           split onto a continuation line.  In this case elm added 2
!           additional addresses into the Cc: line - made up of the 2
!           parts of the full name each with the original senders domain
!           name suffixed on.
!
!
! EB47  Version:     2.4PL13          Status:     Open
!       Open Date:   3-Dec-92         Close Date:
!       Reported by: morwyn![e-mail] (Forrest Aldrich)
!       Summary:     Only last line of each header can be edited
!       Description:
!           The header editor only allows the editing of the last screen
!           line of a header.  Backing up to previous lines is not
!           possible.
!
!
!
! Utilities bugs
! ~~~~~~~~~~~~~~
!
!
! UB02  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Newmail cannot handle null From: headers.
!       Description:
!           Newmail(1) displays a null "From" when a message does not
!           contain a From: header line. It needs to be able to parse the
!           return path and display the "last two words" of it, just like
!           elm(1) does  when it encounters a message without a From:
!
!
! UB07  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Arepdaemon does not check user permissions.
!       Description:
!           Arepdaemon has a bad security hole because it does not check
!           to see if the user can read the file used for reply.
!
!
! UB09  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Arepdeamon does not check status when unlinking data file.
!       Description:
!           Autoreply.c tries to unlink the file "/etc/autoreply.data"
!           when there is only one entry in it and does not check the
!           return value of unlink. This can have bad repercussions if the
!           unlink fails because the program nevertheless reports success.
!
!
! UB13  Version:     2.4PL0           Status:     Open
!       Open Date:   1-Oct-92         Close Date:
!       Reported by: Elm Development Group <[e-mail]>
!       Summary:     Filter has no locking against multiple instantiations.
!       Description:
!           If filter is run on a system that allows multiple delivery
!           agents, that can start up multiple copies of filter, delivery
!           of messages can get intermixed.  Filter needs a complete
!           interlocking to prevent this.
!
!
! -- end of elm bug database



--
========================================================================
Sydney S. Weinstein, CDP, CCP          Elm Coordinator - Current 2.4PL17
Datacomp Systems, Inc.                 Projected 3.0 Release: ??? ?,1994
[e-mail] or dsinc!syd      Voice: [phone], FAX: [phone]